Well the arguments raised in #9623 still stand, I'm not sure such a pixel-art-specific method should be added to Image. Colors are floats so in most cases the comparison will return false, even if it's 99.999% the same color.

What's your use case? If it's for image edition (to save a modified image to disk) I can understand, but if it's just because you want to change some colors in-game, use a shader, it will be 100 times faster.

I keep my point on view on that is still the same. That's too specific use case, which could be handled with a shader. Such image processing belong to a GDNative plugin.

color indexing and palette swapping is such a huge part of gamedev though. The 8bit and 16 bit era games are built on it.

A lot of 2d indie games strive for that look and heavily rely on it :)
Not sure if this implementation is the best way to do it efficiently, but this has been requested a couple of times
#18269
#12670

Once again this can be done with a simple shader. Which is a way more pertinent way of handling color palettes.

I need it for my pixel tool I know a shader would be faster but that doesn't work in my case.

This is probably not the fastest way yes.. but works with 1000x1000 thats fine for now.

The fill function looks in the same category to me so why not. User who are new to gamedev have no clue about shaders they work with Image.

I tried GDNative a few months ago and ran into some bugs.

About the float topic not sure if this is the case. I transform my color to html I can use the color picker to change to any color I want (I know the previous color).

With this you can make different sets of sprites nice in pixel art (for beginners).

The question if whether such tool or not should be implemented in the core. For me the answer is no, since it's a corner case feature that will help only few people.

Since it needs performances, it should be implemented via GDNative.

I am wondering, for my use case (recolor a map texture which is drawn pixel by pixel), how would one do it in shaders if this does not go in?

Colors are floats so in most cases the comparison will return false

Then a solution would be to not use get/set_color, which are slow, but convert the 2 colors into their data representation (1 to 4 bytes) with threshould rounding if needed (easier if we target only specific formats), and run replacement on that directly. It's way more efficient and won't suffer float precision issues if color arguments are picked correctly before the replacement loop. Such optimization would make sense only in C++ though, since GDScript has no language tools to do so.

If GDNative is too much of an undertaking for such a simple operation, a shader is more efficient at this and non-destructive. This is the modern way to do realtime color swappings.
But to be used in a painting program it needs good understanding of viewports, textures and of course shaders. It also cannot be a synchronous operation if done that way, because you need to wait 1 frame for the shader to take effect and get back your modified image.
@Zireael07 I made one, which I used to replace black outlines with red for a damage flickering effect, unfortunately I don't have access to it right now. Maybe later when I get back home. It basically checks the distance between the pixel color and the key color, and outputs the target color if under a threshold (which would be something like 0.01 if you need to replace 1 specific color).

Edit: here is a project showing a colorkey shader:
ColorKeyShader.zip

What is the difference between read and write? Why does write also work on the read operation.
https://github.com/godotengine/godot/blob/master/core/image.cpp#L846

@akien-mga From the previous discussion:

It seems indeed quite limited to low-res pixel art games

I don't think that is bad, as Godot is used a lot for such games, and one of the things that sets us apart from others is that we do support such games as much as big, 3D ones.

IMHO, the method name just needs to make clear that it won't work with anything but small, exact values.

Well, if adding such a feature it should be as @Zylann described it, or as the magic wand in GIMP works: you give a base color and a threshold/precision, and it will replace all pixels within base_color ± threshold.

Ah, yeah that would indeed be better.

Yeah adding threshold is a good addtition.

So simply something like float threshold=0.0 right? Or do you think a Vector4 makes sense too?

Closing this, as there is no consensus on adding more Image editing methods to the Image class.

It may make sense to add Image.set_pixels(array) and Image.set_pixelsv(array) methods to speed this up when doing it from GDScript.

For this PR, a workable alternative may be to use GDNative. Still, thank you for your effort!